The present invention relates to a method and system for resource management in a distributed object architecture and, more particularly, to a method and system for recovering resources allocated on a server on behalf of processes running on a client when the processes on the client no longer need to access the resource or when they terminate normally or abnormally.
Common Object Request Broker Architecture (CORBA) is an industry standard architecture developed by the Object Management Group (OMG) for object-oriented computing in a distributed environment. A CORBA-based system is composed of cooperating objects on a software bus, which is called the object request broker (ORB). Each object has an interface, which in CORBA is an abstract, language-independent representation of the set of methods that can be understood by the object. Method invocations on remote objects occur through an underlying protocol, which can be specific to an ORB vendor or based on an industry standard. The ORB enables objects to make requests and receive responses transparently in a distributed environment.
CORBA 2.0 specifies an interoperability protocol, Internet Inter-ORB Protocol (IIOP), that allows objects implemented using one vendor""s ORB to communicate with an object using another vendor""s ORB. An application developer is shielded from all details of the lower-level interaction, including the locations of the objects and the marshaling (i.e., encoding to convert interfaces and parameters into flattened message formats to transfer over a network) and unmarshalling (i.e., decoding) of arguments.
Interface Definition Language (IDL) is essential to interoperability of components in a CORBA system. IDL is a neutral intermediate language that specifies a component""s boundaries, interfaces with potential clients, or any description of a resource or service that the server component wants to expose to a client. IDL is not a programming language; it is instead a language for expressing interface types.
Several commercial implementations of the CORBA standard exist. Orbix, developed by Iona Technologies, is one such implementation that may be used in methods and systems consistent with the present invention. Orbix consists of a CORBA 2.0-compliant object request broker (ORB), an IDL compiler, and related tools. The ORB mediates between clients and implementations of application objects and must provide a standard interface to such clients, and another to such implementations of application objects. The CORBA standard does not specify whether the ORB is a set of runtime libraries, a set of daemon processes, a server machine, or part of an operating system.
Orbix is implemented as a pair of librariesxe2x80x94one for client applications and one for serversxe2x80x94and the orbixd daemon. The orbixd daemon need only be present at nodes running CORBA servers, and it is responsible for launching server processes dynamically. Because of the library implementation of Orbix ORB, there is no central component through which all object requests must pass. Instead, object requests pass directly from the client (application) code to the invoked server object implementation. If the server and client are in different processes, the method invocation is marshalled in the client process, transmitted over an IP network, unmarshalled in the server process, and dispatched to the appropriate server object by the object adaptor. The role of orbixd is to connect clients and servers for the first time. Since Orbix adheres to IIOP, the Orbix ORB can interoperate with any other ORB that also supports the standard IIOP.
Another important component of Orbix is its compiler technology, which translates CORBA IDL into programming language code, e.g., C++, that performs remote calls. The generated code is sufficiently sophisticated so that developers are not burdened with extra programming steps after translation.
According to CORBA standards, a client may request that a server-side object be created on a server. The server-side object provides a service to its clients through the ORB. When the client no longer needs access to the server-side object, the object should be destroyed. Otherwise, if a client crashes, the objects created on its behalf on the server are abandoned. These server-side objects consume finite operating system (OS) resources (e.g., memory). Without proper management, the server process hosting the server-side objects would eventually run out of available OS resources. The CORBA standards, however, do not address this issue of distributed resource management, i.e., there is no specified method or technique for deleting server-side objects when they are no longer needed by a client. This is because the resource management model of CORBA is based on reference counting on the client side and server side separately, with no interaction between them.
The present invention provides a method for resource management in a CORBA environment that uses smart proxies, a feature of certain CORBA implementations, in connection with reference counting logic on the server to track objects allocated for clients. When a client explicitly releases an object, exits, or crashes, methods consistent with the present invention remove objects that are no longer necessary.
A method consistent with the present invention manages resources in a distributed object-oriented client/server computer system having a garbage collector by receiving at the server a request from the client to create an object, creating the object on the server in response to the request, setting a reference count of the object to one, registering the object with the garbage collector, storing a reference to the object in the garbage collector, thereby incrementing the reference count by one, and returning the reference to the object from the server to the client, thereby decrementing the reference count of the object by one.
Another method consistent with the present invention manages resources by receiving at the server an object-oriented, language-independent message from the client that the client has a reference to the object, determining whether the object was created by the client, incrementing the reference count of the object by one if the object was not created by the client, and storing a reference to the object in the garbage collector if the object was not created by the client.
Another method consistent with the present invention manages resources by receiving at the server a notification that a client has crashed, determining from a table corresponding to the client which objects are used by the client, releasing the objects used by the client, thereby decrementing by one the reference count of the objects used by the client, and removing from the garbage collector the table corresponding to the client.
Yet another method consistent with the present invention manages resources by receiving at the server an object-oriented, language-independent request from the client to delete an object, de-registering the object with the garbage collector, releasing the object, thereby decrementing the reference count of the object by one, and removing from the garbage collector the reference to the object.
Additional features and advantages of the present invention will be readily appreciated by one of ordinary skill in the art from the following detailed description of the best mode for carrying out the invention when taken in connection with the accompanying drawings.